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Abstract 


Traditional finite-field-based Diffie-Hellman (DH) key exchange 
during the Transport Layer Security (TLS) handshake suffers from a 
number of security, interoperability, and efficiency shortcomings. 
These shortcomings arise from lack of clarity about which DH group 
parameters TLS servers should offer and clients should accept. This 
document offers a solution to these shortcomings for compatible peers 
by using a section of the TLS "Supported Groups Registry" (renamed 
from "EC Named Curve Registry" by this document) to establish common 
finite field DH parameters with known structure and a mechanism for 
peers to negotiate support for these groups. 


This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), 
and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography 
(ECC) extensions (RFC 4492). 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7919. 
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1. Introduction 


Traditional TLS [RFC5246] offers a Diffie-Hellman Ephemeral (DHE) key 
exchange mode that provides forward secrecy for the connection. The 
client offers a cipher suite in the ClientHello that includes DHE, 
and the server offers the client group parameters generator g and 
modulus p. If the client does not consider the group strong enough 
(e.g., p is too small, p is not prime, or there are small subgroups 
that cannot be easily avoided) or if it is unable to process the 
group for other reasons, the client has no recourse but to terminate 
the connection. 


Conversely, when a TLS server receives a suggestion for a DHE cipher 
suite from a client, it has no way of knowing what kinds of DH groups 
the client is capable of handling or what the client’s security 
requirements are for this key exchange session. For example, some 
widely distributed TLS clients are not capable of DH groups where p > 
1024 bits. Other TLS clients may, by policy, wish to use DHE only if 
the server can offer a stronger group (and are willing to use a non- 
PFS (Perfect Forward Secrecy) key exchange mechanism otherwise). The 
server has no way of knowing which type of client is connecting but 
must select DH parameters with insufficient knowledge. 


Additionally, the DH parameters selected by the server may have a 
known structure that renders them secure against a small subgroup 
attack, but a client receiving an arbitrary p and g has no efficient 
way to verify that the structure of a new group is reasonable for 
use. 


This modification to TLS solves these problems by using a section of 
the "Supported Groups Registry" (renamed from "EC Named Curve 
Registry" by this document) to select common DH groups with known 
structure and defining the use of the "elliptic_curves(10)" extension 
(described here as the Supported Groups extension) for clients 
advertising support for DHE with these groups. This document also 
provides guidance for compatible peers to take advantage of the 
additional security, availability, and efficiency offered. 


The use of this mechanism by one compatible peer when interacting 
with a non-compatible peer should have no detrimental effects. 


This document updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 
1.2 [RFC5246], as well as the TLS ECC extensions [RFC4492]. 
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1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.2. Vocabulary 


The terms "DHE" or "FFDHE" are used in this document to refer to the 
finite-field-based Diffie-Hellman ephemeral key exchange mechanism in 
TLS. TLS also supports Elliptic Curve Diffie-Hellman Ephemeral 
(ECDHE) key exchanges [RFC4492], but this document does not document 
their use. A registry previously used only by ECDHE-capable 
implementations is expanded in this document to cover FFDHE groups as 
well. "FFDHE cipher suites" is used in this document to refer 
exclusively to cipher suites with FFDHE key exchange mechanisms, but 
note that these suites are typically labeled with a TLS_DHE_ prefix. 


2. Named Group Overview 


We use previously unallocated codepoints within the extension 
currently known as "elliptic_curves" (Section 5.1.1. of [RFC4492]) to 
indicate known finite field groups. The extension’s semantics are 
expanded from "Supported Elliptic Curves" to "Supported Groups". The 
enum datatype used in the extension has been renamed from NamedCurve 
to NamedGroup. Its semantics are likewise expanded from "named 
curve" to "named group". 


Additionally, we explicitly relax the requirement about when the 
Supported Groups extension can be sent. This extension MAY be sent 
by the client when either FFDHE or ECDHE cipher suites are listed. 


Codepoints in the "Supported Groups Registry" with a high byte of 
0x01 (that is, between 256 and 511, inclusive) are set aside for 
FFDHE groups, though only a small number of them are initially 
defined and we do not expect many other FFDHE groups to be added to 
this range. No codepoints outside of this range will be allocated to 
FFDHE groups. The new codepoints for the "Supported Groups Registry" 
are: 


enum { 

// other already defined elliptic curves (see RFC 4492) 
ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258), 
ffdhe6144 (259), ffdhe8192 (260), 

// 

} NamedGroup; 
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These additions to the "Supported Groups Registry" are described in 
detail in Appendix A. They are all safe primes derived from the base 
of the natural logarithm ("e"), with the high and low 64 bits set to 
1 for efficient Montgomery or Barrett reduction. 


The use of the base of the natural logarithm here is as a "nothing-— 
up-my-sleeve" number. The goal is to guarantee that the bits in the 
middle of the modulus are effectively random, while avoiding any 
suspicion that the primes have secretly been selected to be weak 
according to some secret criteria. [RFC3526] used pi for this value. 
See Section 8.5 for reasons that this document does not reuse pi. 


3. Client Behavior 


A TLS client that is capable of using strong finite field Diffie- 
Hellman groups can advertise its capabilities and its preferences for 
stronger key exchange by using this mechanism. 


The compatible client that wants to be able to negotiate strong FFDHE 
sends a Supported Groups extension (identified by type 
elliptic_curves(10) in [RFC4492]) in the ClientHello and includes a 
list of known FFDHE groups in the extension data, ordered from most 
preferred to least preferred. If the client also supports and wants 
to offer ECDHE key exchange, it MUST use a single Supported Groups 
extension to include all supported groups (both ECDHE and FFDHE 
groups). The ordering SHOULD be based on client preference, but see 
Section 6.1 for more nuance. 


A client that offers a Supported Groups extension containing an FFDHE 
group SHOULD also include at least one FFDHE cipher suite in the 
ClientHello. 


A client that offers a group MUST be able and willing to perform a DH 
key exchange using that group. 


A client that offers one or more FFDHE groups in the Supported Groups 
extension and an FFDHE cipher suite and that receives an FFDHE cipher 
suite from the server SHOULD take the following steps upon receiving 
the ServerKeyExchange: 


o For non-anonymous cipher suites where the offered certificate is 
valid and appropriate for the peer, validate the signature over 
the ServerDHParams. If not valid, terminate the connection. 
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o If the signature over ServerDHParams is valid, compare the 
selected dh_p and dh_g with the FFDHE groups offered by the 
client. If none of the offered groups match, the server is not 
compatible with this document. The client MAY decide to continue 
the connection if the selected group is acceptable under local 
policy, or it MAY decide to terminate the connection with a fatal 
insufficient_security(71) alert. 


o If the client continues (either because the server offered a 
matching group or because local policy permits the offered custom 
group), the client MUST verify that dh_Ys is in the range 1 < 
dh_Ys < dh_p- Ta If dh_Ys is not in this range, the client MUST 
terminate the connection with a fatal handshake_failure(40) alert. 


o If dh_Ys is in range, then the client SHOULD continue with the 
connection as usual. 


3.1. Client Local Policy on Custom Groups 


Compatible clients that are willing to accept FFDHE cipher suites 
from non-compatible servers may have local policy about what custom 
FFDHE groups they are willing to accept. This local policy presents 
a risk to clients, who may accept weakly protected communications 
from misconfigured servers. 


This document cannot enumerate all possible safe local policy (the 
safest may be to simply reject all custom groups), but compatible 
clients that accept some custom groups from the server MUST do at 
least cursory checks on group size and may take other properties into 
consideration as well. 


A compatible client that accepts FFDHE cipher suites using custom 
groups from non-compatible servers MUST reject any group with |dh_p| 
< 768 bits and SHOULD reject any group with |dh_p| < 1024 bits. 


A compatible client that rejects a non-compatible server’s custom 
group may decide to retry the connection while omitting all FFDHE 
cipher suites from the ClientHello. A client SHOULD only use this 
approach if it successfully verified the server’s expected signature 
over the ServerDHParams, to avoid being forced by an active attacker 
into a non-preferred cipher suite. 
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4. 


Server Behavior 


If a compatible TLS server receives a Supported Groups extension from 
a client that includes any FFDHE group (i.e., any codepoint between 
256 and 511, inclusive, even if unknown to the server), and if none 
of the client-proposed FFDHE groups are known and acceptable to the 
server, then the server MUST NOT select an FFDHE cipher suite. In 
this case, the server SHOULD select an acceptable non-FFDHE cipher 
suite from the client’s offered list. If the extension is present 
with FFDHE groups, none of the client’s offered groups are acceptable 
by the server, and none of the client’s proposed non-FFDHE cipher 
suites are acceptable to the server, the server MUST end the 
connection with a fatal TLS alert of type insufficient_security(71). 


If at least one FFDHE cipher suite is present in the client cipher 
suite list and the Supported Groups extension is either absent from 
the ClientHello entirely or contains no FFDHE groups (i.e., no 
codepoints between 256 and 511, inclusive), then the server knows 
that the client is not compatible with this document. In this 
scenario, a server MAY select a non-FFDHE cipher suite, or it MAY 
select an FFDHE cipher suite and offer an FFDHE group of its choice 
to the client as part of a traditional ServerKeyExchange. 


A compatible TLS server that receives the Supported Groups extension 
with FFDHE codepoints in it and that selects an FFDHE cipher suite 
MUST select one of the client’s offered groups. The server indicates 
the choice of group to the client by sending the group’s parameters 
as usual in the ServerKeyExchange as described in Section 7.4.3 of 
[RFC5246]. 


A TLS server MUST NOT select a named FFDHE group that was not offered 
by a compatible client. 


A TLS server MUST NOT select an FFDHE cipher suite if the client did 
not offer one, even if the client offered an FFDHE group in the 
Supported Groups extension. 


If a non-anonymous FFDHE cipher suite is selected and the TLS client 
has used this extension to offer an FFDHE group of comparable or 
greater strength than the server’s public key, the server SHOULD 
select an FFDHE group at least as strong as the server’s public key. 
For example, if the server has a 3072-bit RSA key and the client 
offers only ffdhe2048 and ffdhe4096, the server SHOULD select 
ffdhe4096. 
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When an FFDHE cipher suite is selected and the client sends a 
ClientKeyExchange, the server MUST verify that 1 < dh_Yc < dh_p- 1. 
If dh_Yc is out of range, the server MUST terminate the connection 
with a fatal handshake_failure(40) alert. 


Optimizations 


In a key exchange with a successfully negotiated known FFDHE group, 
both peers know that the group in question uses a safe prime as a 
modulus and that the group in use is of size p-1 or (p-1)/2. This 
allows at least three optimizations that can be used to improve 
performance. 


Checking the Peer’s Public Key 


Peers MUST validate each other’s public key Y (dh_Ys offered by the 
server or dh_Yc offered by the client) by ensuring that 1 < Y < p-l. 
This simple check ensures that the remote peer is properly behaved 
and isn’t forcing the local system into the 2-element subgroup. 


To reach the same assurance with an unknown group, the client would 
need to verify the primality of the modulus, learn the factors of 
p-1, and test both the generator g and Y against each factor to avoid 
small subgroup attacks. 


Short Exponents 


Traditional finite field Diffie-Hellman has each peer choose their 
secret exponent from the range [2, p-2]. Using exponentiation by 
squaring, this means each peer must do roughly 2*log_2(p) 
multiplications, twice (once for the generator and once for the 
peer’s public key). 


Peers concerned with performance may also prefer to choose their 
secret exponent from a smaller range, doing fewer multiplications, 
while retaining the same level of overall security. Each named group 
indicates its approximate security level and provides a lower bound 
on the range of secret exponents that should preserve it. For 
example, rather than doing 2*2*3072 multiplications for an ffdhe3072 
handshake, each peer can choose to do 2%*2*275 multiplications by 
choosing their secret exponent from the range [2%°274, 2%°275] (that 
is, an m-bit integer where m is at least 275) and still keep the same 
approximate security level. 


A similar short-exponent approach is suggested in a Secure SHell 
(SSH) Diffie-Hellman key exchange (see Section 6.2 of [RFC4419]). 
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5.3. Table Acceleration 


Peers wishing to further accelerate FFDHE key exchange can also pre- 
compute a table of powers of the generator of a known group. This is 
a memory vs. time trade-off, and it only accelerates the first 
exponentiation of the ephemeral DH exchange (the fixed-base 
exponentiation). The variable-base exponentiation (using the peer’s 
public exponent as a base) still needs to be calculated as normal. 


6. Operational Considerations 


6.1. Preference Ordering 


The ordering of named groups in the Supported Groups extension may 
contain some ECDHE groups and some FFDHE groups. These SHOULD be 
ranked in the order preferred by the client. 


However, the ClientHello also contains a list of desired cipher 
suites, also ranked in preference order. This presents the 
possibility of conflicted preferences. For example, if the 
ClientHello contains a cipher_suite field with two choices in order 
<TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 

TLS_ECDHE_RSA_WITH_AES_128 CBC_SHA> and the Supported Groups 
extension contains two choices in order <secp256r1,ffdhe3072>, then 
there is a clear contradiction. Clients SHOULD NOT present such a 
contradiction since it does not represent a sensible ordering. A 
server that encounters such a contradiction when selecting between an 
ECDHE or FFDHE key exchange mechanism while trying to respect client 
preferences SHOULD give priority to the Supported Groups extension 
(in the example case, it should select 

TLS_ECDHE_RSA_WITH_AES_128 CBC_SHA with secp256r1) but MAY resolve 
the contradiction any way it sees fit. 


More subtly, clients MAY interleave preferences between ECDHE and 
FFDHE groups; for example, if stronger groups are preferred 
regardless of cost, but weaker groups are acceptable, the Supported 
Groups extension could consist of 

<ffdhe8192,secp384p1, ffdhe3072,secp256r1l>. In this example, with the 
same cipher_suite field offered as the previous example, a server 
configured to respect client preferences and with support for all 
listed groups SHOULD select TLS_DHE_RSA_WITH_AES_128_CBC_SHA with 
ffdhe8192. A server configured to respect client preferences and 
with support for only secp384pl1 and ffdhe3072 SHOULD select 
TLS_ECDHE_RSA_WITH_AES_128 CBC_SHA with secp384pl. 
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7. 


IANA Considerations 


This document renames the "EC Named Curve Registry" (originally 
defined in [RFC4492] and updated by [RFC7027]) to the "Supported 
Groups Registry". See 
<https://www.iana.org/assignments/tls-parameters>. 


This document expands the semantics of this registry to include 
groups based on finite fields in addition to groups based on elliptic 
curves. IANA has added a range designation to the registry, 
indicating that values from 256-511 (inclusive) are set aside for 
"Finite Field Diffie-Hellman groups" and that all other entries in 
the registry are "Elliptic curve groups". 


This document allocates five well-defined codepoints in the registry 
for specific finite field Diffie-Hellman groups defined in 
Appendix A. 


In addition, the four highest codepoints in the range 508-511, 
inclusive, are designated for Private Use [RFC5226] by peers who have 
privately developed finite field Diffie-Hellman groups that they wish 
to signal internally. 


The updated registry section is as follows: 


+--------- +------------- +--------- +----------- + 
| Value | Description | DTLS-OK | Reference | 
+--------- +------------- +--------- +----------- + 
| 256 | ffdhe2048 | Y | RFC 7919 | 
| 257 | £fdhe3072 | y | RFC 7919 | 
| 258 | ffdhe4096 | Y | RFC 7919 | 
| 259 | ffdhe6144 | y | RFC 7919 | 
| 260 | ffdhe8192 lex | RFC 7919 | 
| 508-511 | Private Use | | RFC 7919 | 
+--------- +------------- +--------- +----------- + 


TANA has also renamed the "elliptic_curves" extension as 
"supported_groups" and added a reference to this document in the 
"ExtensionType Values" registry. See 
<http://www.iana.org/assignments/tls-extensiontype-values>. 
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8. Security Considerations 
8.1. Negotiation Resistance to Active Attacks 


Because the contents of the Supported Groups extension are hashed in 
the Finished message, an active Man in the Middle (MITM) that tries 
to filter or omit groups will cause the handshake to fail, but 
possibly not before getting the peer to do something it would not 
otherwise have done. 


An attacker who impersonates the server can try to do any of the 
following: 


o Pretend that a non-compatible server is actually capable of this 
extension and select a group from the client’s list, causing the 
client to select a group it is willing to negotiate. It is 
unclear how this would be an effective attack. 


o Pretend that a compatible server is actually non-compatible by 
negotiating a non-FFDHE cipher suite. This is no different than 
MITM cipher suite filtering. 


o Pretend that a compatible server is actually non-compatible by 
negotiating a DHE cipher suite with a custom (perhaps weak) group 
selected by the attacker. This is no worse than the current 
scenario and would require the attacker to be able to sign the 
ServerDHParams, which should not be possible without access to the 
server’s secret key. 


An attacker who impersonates the client can try to do the following: 


o Pretend that a compatible client is not compatible (e.g., by not 
offering the Supported Groups extension or by replacing the 
Supported Groups extension with one that includes no FFDHE 
groups). This could cause the server to negotiate a weaker DHE 
group during the handshake or to select a non-FFDHE cipher suite, 
but it would fail to complete during the final check of the 
Finished message. 


o Pretend that a non-compatible client is compatible (e.g., by 
adding the Supported Groups extension or by adding FFDHE groups to 
the extension). This could cause the server to select a 
particular named group in the ServerKeyExchange or to avoid 
selecting an FFDHE cipher suite. The peers would fail to compute 
the final check of the Finished message. 
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o Change the list of groups offered by the client (e.g., by removing 
the stronger of the set of groups offered). This could cause the 
server to negotiate a weaker group than desired, but again, should 
be caught by the check in the Finished message. 


8.2. Group Strength Considerations 


TLS implementations using FFDHE key exchange should consider the 
strength of the group they negotiate. The strength of the selected 
group is one of the factors that define the connection’s resilience 
against attacks on the session’s confidentiality and integrity, since 
the session keys are derived from the DHE handshake. 


While attacks on integrity must generally happen while the session is 
in progress, attacks against session confidentiality can happen 
significantly later if the entire TLS session is stored for offline 
analysis. Therefore, FFDHE groups should be selected by clients and 
servers based on confidentiality guarantees they need. Sessions that 
need extremely long-term confidentiality should prefer stronger 
groups. 


[ENISA] provides rough estimates of group resistance to attack and 
recommends that forward-looking implementations ("future systems") 
should use FFDHE group sizes of at least 3072 bits. ffdhe3072 is 

intended for use in these implementations. 


Other sources (e.g., [NIST]) estimate the security levels of the 
Discrete Log (DLOG) problem to be slightly more difficult than 
[ENISA]. This document’s suggested minimum exponent sizes in 
Appendix A for implementations that use the short-exponent 
optimization (Section 5.2) are deliberately conservative to account 
for the range of these estimates. 


8.3. Finite Field DHE Only 
Note that this document specifically targets only finite field 
Diffie-Hellman ephemeral key exchange mechanisms. It does not cover 
the non-ephemeral DH key exchange mechanisms, nor does it address 


ECDHE key exchange, which is defined in [RFC4492]. 


Measured by computational cost to the TLS peers, ECDHE appears today 
to offer a much stronger key exchange mechanism than FFDHE. 
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8.4. Deprecating Weak Groups 


Advances in hardware or in finite field cryptanalysis may cause some 
of the negotiated groups to not provide the desired security margins, 
as indicated by the estimated work factor of an adversary to discover 
the premaster secret (and may therefore compromise the 
confidentiality and integrity of the TLS session). 


Revisions of this document should mark known weak groups as 
explicitly deprecated for use in TLS and should update the estimated 
work factor needed to break the group if the cryptanalysis has 
changed. Implementations that require strong confidentiality and 
integrity guarantees should avoid using deprecated groups and should 
be updated when the estimated security margins are updated. 


8.5. Choice of Groups 


Other lists of named finite field Diffie-Hellman groups 
[STRONGSWAN-IKE] exist. This document chooses to not reuse them for 
several reasons: 


o Using the same groups in multiple protocols increases the value 
for an attacker with the resources to crack any single group. 


o The Internet Key Exchange Protocol (IKE) groups include weak 
groups like MODP768 that are unacceptable for secure TLS traffic. 


o Mixing group parameters across multiple implementations leaves 
open the possibility of some sort of cross-protocol attack. This 
shouldn’t be relevant for ephemeral scenarios, and even with non- 
ephemeral keying, services shouldn’t share keys; however, using 
different groups avoids these failure modes entirely. 


8.6. Timing Attacks 


Any implementation of finite field Diffie-Hellman key exchange should 
use constant-time modular-exponentiation implementations. This is 
particularly true for those implementations that ever reuse DHE 
secret keys (so-called "Semi-static" ephemeral keying) or share DHE 
secret keys across a multiple machines (e.g., in a load-balancer 
situation). 
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8.7. Replay Attacks from Non-negotiated FFDHE 


[SECURE-RESUMPTION], [CROSS-PROTOCOL], and [SSL3-ANALYSIS] all show a 
malicious peer using a bad FFDHE group to maneuver a client into 
selecting a premaster secret of the peer’s choice, which can be 
replayed to another server using a non-FFDHE key exchange and can 
then be bootstrapped to replay client authentication. 


To prevent this attack (barring the session hash fix documented in 
[RFC7627]), a client would need not only to implement this document, 
but also to reject non-negotiated FFDHE cipher suites whose group 
structure it cannot afford to verify. Such a client would need to 
abort the initial handshake and reconnect to the server in question 
without listing any FFDHE cipher suites on the subsequent connection. 


This trade-off may be too costly for most TLS clients today but may 
be a reasonable choice for clients performing client certificate 
authentication or for clients who have other reasons to be concerned 
about server-controlled premaster secrets. 


8.8. Forward Secrecy 


One of the main reasons to prefer FFDHE ciphersuites is forward 
secrecy, the ability to resist decryption even if the endpoint’s 
long-term secret key (usually RSA) is revealed in the future. 


This property depends on both sides of the connection discarding 

their ephemeral keys promptly. Implementations should wipe their 
FFDHE secret key material from memory as soon as it is no longer 

needed and should never store it in persistent storage. 


Forward secrecy also depends on the strength of the Diffie-Hellman 
group; using a very strong symmetric cipher like AES256 with a 
forward-secret cipher suite but generating the keys with a much 
weaker group like dhe2048 simply moves the adversary’s cost from 
attacking the symmetric cipher to attacking the dh_Ys or dh_Yc 
ephemeral key shares. 


If the goal is to provide forward secrecy, attention should be paid 
to all parts of the cipher suite selection process, both key exchange 
and symmetric cipher choice. 


8.9. False Start 
Clients capable of TLS False Start [RFC7918] may receive a proposed 
FFDHE group from a server that is attacker controlled. In 


particular, the attacker can modify the ClientHello to strip the 
proposed FFDHE groups, which may cause the server to offer a weaker 
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FFDHE group than it should, and this will not be detected until 
receipt of the server’s Finished message. This could cause a client 
using the False Start protocol modification to send data encrypted 
under a weak key agreement. 


Clients should have their own classification of FFDHE groups that are 
"cryptographically strong" in the same sense described in the 
description of symmetric ciphers in [RFC7918] and SHOULD offer at 
least one of these in the initial handshake if they contemplate using 
the False Start protocol modification with an FFDHE cipher suite. 


Compatible clients performing a full handshake MUST NOT use the False 
Start protocol modification if the server selects an FFDHE cipher 
suite but sends a group that is not cryptographically strong from the 
client’s perspective. 


9. Privacy Considerations 
9.1. Client Fingerprinting 


This extension provides a few additional bits of information to 
distinguish between classes of TLS clients (e.g., see 
[PANOPTICLICK]). To minimize this sort of fingerprinting, clients 
SHOULD support all named groups at or above their minimum security 
threshold. New groups SHOULD NOT be added to the "Supported Groups 
Registry" without consideration of the cost of browser 
fingerprinting. 
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Appendix A. Supported Groups Registry (Formerly "EC Named Curve 
Registry") 


Each description below indicates the group itself, its derivation, 
its expected strength (estimated roughly from guidelines in 
[ECRYPTII]), and whether it is recommended for use in TLS key 
exchange at the given security level. It is not recommended to add 
further finite field groups to the "Supported Groups Registry"; any 
attempt to do so should consider Section 9.1. 


The primes in these finite field groups are all safe primes; that is, 
a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is 
the base of the natural logarithm and square brackets denote the 
floor operation, the groups that initially populate this registry are 
derived for a given bit length b by finding the lowest positive 
integer X that creates a safe prime p where: 


p = 2%b - 2%{b-64} + {[2%{b-130} e] + X } * 2^64 - 1 

New additions of FFDHE groups to this registry may use this same 
derivation (e.g., with different bit lengths) or may choose their 
parameters in a different way, but they must be clear about how the 


parameters were derived. 


New additions of FFDHE groups MUST use a safe prime as the modulus to 
enable the inexpensive peer verification described in Section 5.1. 


A.1. ffdhe2048 


The 2048-bit group has registry value 256 and is calculated from the 
following formula: 


The modulus is: 


p = 2%2048 - 2%1984 + {[2%1918 * e] + 560316 } * 2%64 = I 
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The hexadecimal representation of p is: 


FFFFFFFF 
D8B9C583 
7D2FE363 
2433F51F 
984F0C70 
30ACCA4F 
B96ADAB7 
OBO7ATC8 
9172FE9C 
3BB5FCBC 
886B4238 


FFFFFFFF 
CE2D3695 
630C75D8 
5SFO66EDO 
EOE68B77 
483A797A 
60D7F468 
EEOA6D70 
E98583FF 
2EC22005 
61285C97 


The generator is: 


The group 


size is: 


ADF85458 
A9E13641 
F681B202 
85636555 
E2A689DA 
BCOAB182 
1D4F42A3 
9E02FCE1 
8E4F 1232 
C58EF183 
FFFFFFFF 


g=2 


q = 


A2BB4A9A 
146433FB 
AEC4617A 
3DED1AF3 
F3EFE872 
B324FB61 
DE394DF4 
CDF 7E2EC 
EEF28183 
7D1683B2 
FFFFFFFF 


(p-1)/2 


AFDC5620 
CC939DCE 
D3DF1ED5 
B557135E 
1DF158A1 
D108A94B 
AES 6EDE7 
C03404CD 
C3FE3B1B 
C6F34A26 


The hexadecimal representation of q is: 


7FFFFFFF 
EC5CE2C1 
BE97F1B1 
9219FA8F 
CC278638 
98566527 
DCB56D5B 


FFFFFFFF 
E7169B4A 
B1863AEC 
AF833768 
707345BB 
A41D3CBD 
BO6BFA34 


8583D3E4 
C8B97F4E 
9DDAFESE 
4435A11C 


770536B8 
74C2C1FF 
17611002 
30942E4B 


D6FC2A2C 
D4F09B20 
7B40D901 
42B1B2AA 
F15344ED 
5E0558C1 
OEA7A151 
4F017E70 
C7278919 
E2C778C1 
FFFFFFFF 


515DA54D 
8A3219FD 
576230BD 
9EF68D79 
TOF TE439 
599277DBO 
EF1ICA6FA 
E6FBF176 
777940C1 
BE8B41D9 
FFFFFFFF 


57EE2B10 
E649CEE7 
69EF8F6A 
DAAB8 9AF 
OEF8AC50 
E88454A5 
572B76F3 
601A0266 
E1LFF1D8D 
6379A513 


273D3CF1 
249B3EF9 
D5FD6561 
TE57C935 
36ADE735 
B2C8E3FB 
6372BB19 
28342F61 
4C6FAD73 
C1IB2EFFA 


139E9E78 
124D9F7C 
EAFEB2BO 
3FABE49A 
9B56F39A 
D96471FD 
B1B95D8C 
941A17B0 
A637D6B9 
60D977FD 


August 2016 


The estimated symmetric-equivalent strength of this group is 103 


bits. 


Peers using ffdhe2048 that want to optimize their key exchange with a 
should choose a secret key of at least 


short exponent 


225 bits. 


ffdhe3072 


(Section 5.2) 


The 3072-bit prime has registry value 257 and is calculated from the 


following 


formula: 


The modulus is: 


p = 2^3072 - 2^3008 + {[2%2942 * e] 


Gillmor 
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The hexadecimal representation of p is: 


FFFFFFFF 
D8B9C583 
7D2FE363 
2433F51F 
984F0C70 
30ACCA4F 
B96ADAB7 
OBO7ATC8 
9172FE9C 
3BB5FCBC 
886B4238 
61B46FC9 
AEFE1309 
64F2E21E 
ABC52197 
3C1B20EE 


FFFFFFFF 
CE2D3695 
630C75D8 
5SFO66EDO 
EOE68B77 
483A797A 
60D7F468 
1EOA6D70 
E98583FF 
2EC22005 
611FCFDC 
D6E6C907 
85139270 
71F54BFF 
9BODEADA 
3FD59D7C 


T 


The generator is: 


The group 


size is: 


ADF85458 
A9E13641 
F681B202 
85636555 
E2A689DA 
BC0AB182 
1D4F42A3 


A2BB4A9A 
146433FB 
AEC4617A 
3DED1AF3 
F3EFE872 
B324FB61 
DE394DF4 


9E02FCE1 
8E4F1232 
C58EF183 
DE355B3B 
7AD91D26 
B4130C93 
5CAE82AB 
1DBF9A42 
25E41D2B 


g=2 


q = 


CDF 7E2EC 
1EF28183 
7D1683B2 
6519035B 
91F7F7EE 
BC437944 
9C9DF69E 
D5C4484E 
66C62E37 


$ 


(p-1)/2 


AFDC5620 
CC939DCE 
D3DF1ED5 
B557135E 
1DF158A1 
D108A94B 
AES 6EDE7 
C03404CD 
C3FE3B1B 
COF34A26 
BC34F4DE 
598CBOFA 
F4FD4452 
E86D2BC5 
OABCDO6B 
FFFFFFFF 


The hexadecimal representation of q is: 


7FFFFFFF 
EC5CE2C1 
BE97F1B1 
9219FA8F 
CC278638 
98566527 
DCB56D5B 
8583D3E4 
C8B97F4E 
9DDAFESE 
4435A11C 
30DA37E4 
577F0984 
B279710F 
D5E290CB 
9EOD9077 


FFFFFFFF 
E7169B4A 
B1863AEC 
AF833768 
707345BB 
A41D3CBD 
BO6BFA34 
770536B8 
74C2C1FF 
17611002 


D6FC2A2C 
D4F09B20 
7B40D901 
42B1B2AA 
F15344ED 
5E0558C1 
OEA7A151 
4F017E70 
C7278919 
E2C778C1 


308FE7EE 


6F1AAD9D 


EB736483 
C289C938 
38FAA5FF 
CD86F56D 
1FEACEBE 


BD6C8E93 
5A098649 
AES74155 
OEDFCD21 
12F20E95 


515DA54D 
8A3219FD 
576230BD 
9EF68D79 
TOF TE439 
599277DBO 
EF1ICA6FA 
E6FBF176 
777940C1 
BE8B41D9 
B28C81AD 
48FBFBF7 
DE21BCA2 
CE4EFB4F 
6AE22427 
B363171B 


57EE2B10 
E64 9CEE7 
69EF8F6A 
DAAB8 9AF 
OEF8AC50 
E88454A5 
572B76F3 
601A0266 
E1FF1D8D 
6379A513 
DE1A7A6F 
2CC6587D 
TATEA229 
743695E2 
055EF6835 
FFFFFFFF 


273D3CF1 
249B3EF9 
D5FD6561 
TE57C935 
36ADE735 
B2C8E3FB 
6372BB19 
28342F61 
4C6FAD73 
C1IB2EFFA 
F99C0238 
C186D91C 
E2D74DD3 
22363A0D 
FA53DDEF 
FFFFFFFF 


139E9E78 
124D9F7C 
EAFEB2BO 
3FABE49A 
9BS6F39A 
D96471FD 
B1B95D8C 
941A17BO 
A637D6B9 
60D977FD 
7TCCEO11C 
60C36C8E 
716BA6E9 
911B1D06 
FD29EEF7 
FFFFFFFF 


August 2016 


The estimated symmetric-equivalent strength of this group is 125 


bits. 


Peers using ffdhe3072 that want to optimize their key exchange with a 
should choose a secret key of at least 


short exponent 


275 bits. 


Gillmor 


(Section 5.2) 
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The 4096-bit group has registry value 258 and is calculated from the 
following formula: 


The modulus is: 


p = 2°4096 - 2%4032 + {[2%3966 * e] 


+ 5736041} 


The hexadecimal representation of p is: 


FFFFFFFF 
D8B9C583 
7D2FE363 
2433F51F 
984F0C70 
30ACCA4F 
B96ADAB7 
OBO7A7TC8 
9172FE9C 
3BB5FCBC 
886B4238 
61B46FC9 
AEFE1309 
64F2E21E 
ABC52197 
3C1B20EE 
7930E9E4 
87F55BA5 
A907600A 
1A1DB93D 
8EC9B55A 
FFFFFFFF 


FFFFFFFF 
CE2D3695 
630C75D8 
5SFO66EDO 
EOE68B77 
483A797A 
60D7F468 
EEOA6D70 
E98583FF 
2EC22005 
611FCFDC 
D6E6C907 
85139270 
71F54BFF 
9BODEADA 
3FD59D7C 
E58857B6 
7E31CC7A 
918130C4 
7140003C 
7E88A46B 
FFFFFFFF 


The generator is: g 


The group 


Gillmor 


size is: 


ADF85458 
A9E13641 
F681B202 
85636555 
E2A689DA 
BC0AB182 
1D4F42A3 
9E02FCE1 
8E4F1232 
C58EF183 
DE355B3B 
7AD91D26 
B4130C93 
5CAE82AB 
1DBF9A42 
25E41D2B 


A2BB4A9A 
146433FB 
AEC4617A 
3DED1AF3 
F3EFE872 
B324FB61 
DE394DF4 
CDF 7E2EC 
EEF28183 
7D1683B2 
6519035B 
91F7F7EE 
BC437944 
9C9DF69E 
D5C4484E 
669R1EF1 


AFDC5620 
CC939DCE 
D3DF1ED5 
B557135E 
1DF158A1 
D108A94B 
AES 6EDE7 
C03404CD 
C3FE3B1B 
C6F34A26 
BC34F4DE 
598CBOFA 
F4FD4452 
E86D2BC5 
OABCDO6B 
6E6F52C3 


ACT7D5F42 
7135C886 
6DC778F9 
2A4ECEAQ 
4DB5A851 


q = 


D69F6D18 
EFB4318A 
71AD0038 
F98DO0ACC 
F44182E1 


7763CF1D 
ED6A1E01 
092999A3 
0A8291CD 
Cé68A007E 


Standards Track 


#2 NO Ai 


273D3CF1 
249B3EF9 
D5FD6561 
TE57C935 
36ADE735 
B2C8E3FB 
6372BB19 
28342F61 
4C6FAD73 
C1IB2EFFA 
F99C0238 
C186D91C 
E2D74DD3 
22363A0D 
FA53DDEF 
164DF4FB 
55034004 
2D9E6832 
33CB8B7A 
CEC97DCF 
5E655F6A 
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The hexadecimal representation of q is: 


7FFFFFFF 
EC5CE2C1 


FFFFFFFF 
E7169B4A 


BE97F1B1 
9219FA8F 
CC278638 
98566527 
DCB56D5B 
8583D3E4 
C8B97F4E 
9DDAFESE 
4435A11C 
30DA37E4 
577F0984 
B279710F 
D5E290CB 
9EOD9077 
BC9874F2 
43FAADD2 
5483B005 
ODOEDC9E 
C764DAAD 
7FFFFFFF 


B1863AEC 
AF833768 
707345BB 
A41D3CBD 
BO6BFA34 
770536B8 
74C2C1FF 
17611002 
308FE7EE 


D6FC2A2C 
D4F09B20 
7B40D901 
42B1B2AA 
F15344ED 
5E0558C1 
OEA7A151 
4F017E70 
C7278919 
E2C778C1 
6F1AAD9D 


515DA54D 
8A3219FD 
576230BD 
9EF68D79 
TOF TE439 
59927DBO 
EF1ICA6FA 
EO6FBF176 
777940C1 
BE8B41D9 
B28C81AD 


EB736483 
C289C938 
38FAA5FF 
CD86F56D 
1FEACEBE 
72C42BDB 
BF18E63D 
48009862 
B8A0001E 
3FC45235 
FFFFFFFF 


BD6C8E93 
5A098649 
AE574155 
OEDFCD21 
12F20E95 
563EAFA1 
389AE443 
36E3BC7C 
15276754 
A6DAD428 


48FBFBF7 
DE21BCA2 
CE4EFB4F 
6AE22427 
B34F0F78 
6B4FB68C 
77DA18C5 
B8D6801C 
FCC68566 
FA20C170 


57EE2B10 
E64 9CEE7 
69EF8F6A 
DAAB8 9AF 
OEF8AC50 
E88454A5 
572B76F3 
601A0266 
E1LFF1D8D 
6379A513 
DE1LA7A6F 
2CC6587D 
TATEA229 
743695E2 
055E6835 
B737A961 
3BB1E78E 
76B50F00 
0494CCD1 
054148E6 
E345003F 


139E9E78 
124D9F7C 
EAFEB2B0 
3FABE4 9A 
9BS6F39A 
D96471FD 
B1B95D8C 
941A17BO 
A637D6B9 
60D977FD 
7CCEO11C 
60C36C8E 
716BA6E9 
911B1D06 
FD29EEF7 
8B26FA7D 
AA81A002 
96CF3419 
99E5C5BD 
E764BEE7 
2F32AFB5 


August 2016 


The estimated symmetric-equivalent strength of this group is 150 


bits. 


Peers using ffdhe4096 that want to optimize their key exchange with a 
short exponent (Section 5.2) should choose a secret key of at least 
325 bits. 

A.4. ffdhe6144 


The 6144-bit group has registry value 259 and is calculated from the 
following formula: 


The modulus is: 


p = 2%6144 - 2%6080 + {[2%6014 * e] + 15705020} * 2^64 - 1 
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The hexadecimal representation of p is: 


FFFFFFFF 
D8B9C583 
7D2FE363 
2433F51F 
984F0C70 
30ACCA4F 
B96ADAB7 
OBO7ATC8 
9172FE9C 
3BB5FCBC 
886B4238 
61B46FC9 
AEFE1309 
64F2E21E 
ABC52197 
3C1B20EE 
7930E9E4 
87F55BA5 
A907600A 
1A1DB93D 
8EC9B55A 
OBFD64B6 
3BB45432 
CDAD0657 
A52471F7 
OABECLFF 
763E4E4B 
B3A739C1 
D72B0374 
E49F5235 
5B3B71F9 
A41D570D 


FFFFFFFF 
CE2D3695 
630C75D8 
5SFO66EDO 
EOE68B77 
483A797A 
60D7F468 
1EOA6D70 
E98583FF 
2EC22005 
611FCFDC 
D6E6C907 
85139270 
71F54BFF 
9BODEADA 
3FD59D7C 
E58857B6 
TE31CC7A 
918130C4 
7140003C 
7E88A46B 
45036C7A 
9B7624C8 
FCCFEC71 


T 


ADF85458 
A9E13641 
F681B202 
85636555 
E2A689DA 
BC0AB182 
1D4F42A3 


A2BB4A9A 
146433FB 
AEC4617A 
3DED1AF3 
F3EFE872 
B324FB61 
DE394DF4 


9E02FCE1 
8E4F1232 
C58EF183 
DE355B3B 
7AD91D26 
B4130C93 
5CAE82AB 
1DBF9A42 
25E41D2B 
AC7D5F42 
7135C886 
6DC778F9 
2A4ECEA9 
4DB5A851 
4E677D2C 
917BDD64 
9B1F5C3E 


CDF 7E2EC 
1EF28183 
7D1683B2 
6519035B 
91F7F7EE 
BC437944 
9C9DF69E 
D5C4484E 
669E1EF1 
D69F6D18 
EFB4318A 
71AD0038 
F98DO0ACC 
F44182E1 
38532A3A 
B1ICOFD4C 
4E46041F 


$ 


A9A96910 
F9E3A26E 
94B2BBC1 
22611682 
6AE77F5E 
C95B9117 
DC6B80D6 
7938DAD4 


The generator is: 


The group 


Gillmor 


size is: 


B855322E 
TEB29F8C 
94C6651E 
OAE8DB58 
62292C31 
8CCF2DD5 
3FDD4A8E 
A40E329C 


g=2 


DB6340D8 
183023C3 
TTICAF 992 
47A67CBE 
1562A846 
CACEF 403 
9ADB1E69 
DOE40E65 


AFDC5620 
CC939DCE 
D3DF1ED5 
B557135E 
1DF158A1 
D108A94B 
AES 6EDE7 
C03404CD 
C3FE3B1B 
COF34A26 
BC34F4DE 
598CBOFA 
F4FD4452 
E86D2BC5 
OABCDO6B 
6E6F52C3 
7763CF1D 
ED6A1E01 
092999A3 
0A8291CD 
C68A007E 
23BA4442 
B38E8C33 
388147FB 
AOOEF092 
587E38DA 
EEAAC023 
F9C9091B 
505DC82D 
EC9D1810 
62A69526 
FFFFFFFF 
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273D3CF1 
249B3EF9 
D5FD6561 
TE57C935 
36ADE735 
B2C8E3FB 
6372BB19 
28342F61 
4C6FAD73 
C1IB2EFFA 
F99C0238 
C186D91C 
E2D74DD3 
22363A0D 
FA53DDEF 
164DF4FB 
55034004 
2D9E6832 
33CB8B7A 
CEC97DCF 
5SEODD902 
CAF53EA6 
4C701C3A 
4CFDB477 
350511E3 
0077D9B4 
2A281BF6 
462D538C 
B854338A 
C6272B04 
D43161C1 
FFFFFFFF 
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The hexadecimal representation of q is: 


7FFFFFFF 
EC5CE2C1 


FFFFFFFF 
E7169B4A 


BE97F1B1 
9219FA8F 
CC278638 
98566527 
DCB56D5B 
8583D3E4 
C8B97F4E 
9DDAFESE 
4435A11C 
30DA37E4 
577F0984 
B279710F 
D5E290CB 
9EOD9077 
BC9874F2 
43FAADD2 
5483B005 
ODOEDC9E 
C764DAAD 
O5FEB25B 
1DDA2A19 
66D6832B 
D29238FB 
855F60FF 
3B1F2725 
59D39CEO 
6B9581BA 
7 

2 


24FA91A 
D9DB8FC 
D20EAB86 


B1863AEC 
AF833768 
707345BB 
A41D3CBD 
BO6BFA34 
770536B8 
74C2C1FF 
17611002 
308FE7EE 


D6FC2A2C 
D4F09B20 
7B40D901 
42B1B2AA 
F15344ED 
5E0558C1 
OEA7A151 
4F017E70 
C7278919 
E2C778C1 
6F1AAD9D 


515DA54D 
8A3219FD 
576230BD 
9EF68D79 
TOF TE439 
59927DBO 
EF1ICA6FA 
EO6FBF176 
777940C1 
BE8B41D9 
B28C81AD 


EB736483 
C289C938 
38FAA5FF 
CD86F56D 
1FEACEBE 
72C42BDB 
BF18E63D 
48009862 
B8A0001E 
3FC45235 
2281B63D 
4DBB1264 
FE67F 638 
D4D4B488 
FCF1D137 
CA595DE0 
91308B41 
3573BFAF 
E4ADC88B 
EE35C06B 
BC9C6D6A 


BD6C8E93 
5A098649 
AE574155 
OEDFCD21 
12F20E95 
563EAFA1 
389AE443 
36E3BC7C 
15276754 
A6DAD428 
2733BE96 
48BDEEB2 
CD8FAE1F 
5C2A9917 
3FD94FC6 
CA63328F 
05746DAC 
31149618 
C66796EA 
1FEEA547 
52071945 


48FBFBF7 
DE21BCA2 
CE4EFB4F 
6AE22427 
B34F0F78 
6B4FB68C 
77DA18C5 
B8D6801C 
FCC68566 
FA20C170 
1029951D 
58E07EA6 
2723020F 
6DB1A06C 
0C1811E1 
3BE57CC9 
23D33E5F 
8AB15423 
E5677A01 
4D6D8F34 
68720732 


57EE2B10 
E64 9CEE7 
69EF8F6A 
DAAB8 9AF 
OEF8AC50 
E88454A5 
572B76F3 
601A0266 
E1LFF1D8D 
6379A513 
DE1LA7A6F 
2CC6587D 
TATEA229 
743695E2 
055E6835 
B737A961 
3BB1E78E 
76B50F00 
0494CCD1 
054148E6 
E345003F 
11DD2221 
59074619 
9C40A3FD 
50077849 
AC3F1C6D 
77556011 
7CE4848D 
282EE416 
F64E8C08 
B1534A93 
FFFFFFFF 


139E9E78 
124D9F7C 
EAFEB2B0 
3FABE4 9A 
9BS6F39A 
D96471FD 
B1B95D8C 
941A17BO 
A637D6B9 
60D977FD 
7CCEO11C 
60C36C8E 
716BA6E9 
911B1D06 
FD29EEF7 
8B26FA7D 
AA81A002 
96CF3419 
99E5C5BD 
E764BEE7 
2F06EC81 
657A9F53 
A6380E1D 
A67EDA3B 
1A8288F1 
OO3BECDA 
95140DFB 
A316A9C6 
DC2A19C5 
63139582 
6A18BOE0 
FFFFFFFF 


August 2016 


The estimated symmetric-equivalent strength of this group is 175 


bits. 


Peers using ffdhe6144 that want to optimize their key exchange with a 
should choose a secret key of at least 


short exponent 


375 bits. 


Gillmor 


(Section 5.2) 
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A.5. f£fdhe8192 


The 8192-bit group has registry value 260 and is calculated from the 
following formula: 


The modulus is: 


p = 2°8192 - 2%8128 + {[2*%8062 * e] + 10965728} * 2*%64 - 1 
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The hexadecimal representation of p is: 


FFFFFFFF 
D8B9C583 
7D2FE363 
2433F51F 
984F0C70 
30ACCA4F 
B96ADAB7 
OBO7ATC8 
9172FE9C 
3BB5FCBC 
886B4238 
61B46FC9 
AEFE1309 
64F2E21E 
ABC52197 
3C1B20EE 
7930E9E4 
87F55BA5 
A907600A 
1A1DB93D 
8EC9B55A 
OBFD64B6 
3BB45432 
CDAD0657 
A52471F7 
OABECLFF 
763E4E4B 
B3A739C1 
D72B0374 
E49F5235 
5B3B71F9 
A41D570D 
1E4254A31 
OB8CC3BD 
CB2COF1C 
2846COBA 
BB709987 
51AA691E 
D5B80194 
1EFC8CEO 


FFFFFFFF 
CE2D3695 
630C75D8 
5SFO66EDO 
EOE68B77 
483A797A 
60D7F468 
1EOA6D70 
E98583FF 
2EC22005 
611FCFDC 
D6E6C907 
85139270 
71F54BFF 
9BODEADA 
3FD59D7C 
E58857B6 
TE31CC7A 
918130C4 
7140003C 
7E88A46B 
45036C7A 
9B7624C8 
FCCFEC71 


T 


ADF85458 
A9E13641 
F681B202 
85636555 
E2A689DA 
BC0AB182 
1D4F42A3 


A2BB4A9A 
146433FB 
AEC4617A 
3DED1AF3 
F3EFE872 
B324FB61 
DE394DF4 


9E02FCE1 
8E4F1232 
C58EF183 
DE355B3B 
7AD91D26 
B4130C93 
5CAE82AB 
1DBF9A42 
25E41D2B 
AC7D5F42 
7135C886 
6DC778F9 
2A4ECEA9 
4DB5A851 
4E677D2C 
917BDD64 
9B1F5C3E 


CDF 7E2EC 
1EF28183 
7D1683B2 
6519035B 
91F7F7EE 
BC437944 
9C9DF69E 
D5C4484E 
669E1EF1 
D69F6D18 
EFB4318A 
71AD0038 
F98DO0ACC 
F44182E1 
38532A3A 
B1ICOFD4C 
4E46041F 


$ 


A9A96910 
F9E3A26E 
94B2BBC1 
22611682 
6AE77F5E 
C95B9117 
DC6B80D6 
7938DAD4 
D951AE64 
F64B10EF 
CO1BD702 
35C35F5C 
6A460E74 
0E423CFC 
88D9C0A0 
BA8A4FE8 


FAFABE1C 
97D11D49 
D68C8BB7 


5D71A87E 
F7A8443D 
C5C6424C 


The generator is: 


Gillmor 


B855322E 
TEB29F8C 
94C6651E 
OAE8DB58 
62292C31 
8CCF2DD5 
3FDD4A8E 
A40E329C 
FDB23FCE 
86B63142 
29388839 
59160CCO 
51A8A931 
99E9E316 
A1FE3075 
B6855DFE 
2F741EF8 
0822E506 
FFFFFFFF 


g=2 


DB6340D8 
183023C3 
TTICAF 992 
47A67CBE 
1562A846 
CACEF 403 
9ADB1E69 
CFF46AAA 
C9509D43 
A3AB8829 
D2AFO5E4 
46FD8251 
09703FEE 
50C1217B 
A577E231 
72BOA66E 


AFDC5620 
CC939DCE 
D3DF1ED5 
B557135E 
1DF158A1 
D108A94B 
AES 6EDE7 
C03404CD 
C3FE3B1B 
COF34A26 
BC34F4DE 
598CBOFA 
F4FD4452 
E86D2BC5 
OABCDO6B 
6E6F52C3 
7763CF1D 
ED6A1E01 
092999A3 
0A8291CD 
C68A007E 
23BA4442 
B38E8C33 
388147FB 
AOOEF092 
587E38DA 
EEAAC023 
F9C9091B 
505DC82D 
EC9D1810 
62A69526 
36AD004C 
687FEB69 
555B2F74 
54504AC7 
541FC68C 
1C217E6C 
624816CD 
83F81D4A 
DED2FBAB 


273D3CF1 
249B3EF9 
D5FD6561 
TE57C935 
36ADE735 
B2C8E3FB 
6372BB19 
28342F61 
4C6FAD73 
C1B2EFFA 
F99C0238 
C186D91C 
E2D74DD3 
22363A0D 
FA53DDEF 
164DF4FB 
55034004 
2D9E6832 
33CB8B7A 
CEC97DCF 
5SEODD902 
CAF53EA6 
4C701C3A 
4CFDB477 
350511E3 
0077D9B4 
2A281BF6 
462D538C 
B854338A 
C6272B04 
D43161C1 
F600C838 
EDD1CC5E 
70932665 
8B758282 
9C86B022 
3826E52C 
AD9A95F9 
3F2FA457 
FBE58A30 


C1FE86FE 


A6BBFDE5 


A9F4614E 
FFFFFFFF 


011E2A94 
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30677F0D 
838FF88C 
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The group 


size is: 
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qe 


(p-1)/2 


The hexadecimal representation of q is: 


7FFFFFFF 
EC5CE2C1 


FFFFFFFF 
E7169B4A 


BE97F1B1 
9219FA8F 
CC278638 
98566527 
DCB56D5B 
8583D3E4 
C8B97F4E 
9DDAFESE 
4435A11C 
30DA37E4 
577F0984 
B279710F 
D5E290CB 
9EOD9077 
BC9874F2 
43FAADD2 
5483B005 
ODOEDC9E 
C764DAAD 
O5FEB25B 
1DDA2A19 
66D6832B 
D29238FB 
855F60FF 
3B1F2725 
59D39CEO 
6B9581BA 
724FA91A 
2D9DB8FC 
D20EAB86 
0F212D18 
05C661DE 
E596078E 
1423605D 
5DB84CC3 
28D5348F 
EADCOOCA 
8F7E4670 
7D7D5F0E 
CBE88EA4 
6B4645DB 


Gillmor 


B1863AEC 
AF833768 
707345BB 
A41D3CBD 
BO6BFA34 
770536B8 
T4C2C1EF 
17611002 
308FE7EE 


D6FC2A2C 
D4F09B20 
7B40D901 
42B1B2AA 
F15344ED 
5E0558C1 
OEA7A151 
4F017E70 
C7278919 
E2C778C1 
6F1AAD 9D 


515DA54D 
8A3219FD 
576230BD 
9EF68D79 
TOF TE439 
59927DBO 
EF1ICA6FA 
EO6FBF176 
777940C1 
BE8B41D9 
B28C81AD 


EB736483 
C289C938 
38FAA5FF 
CD86F56D 
1FEACEBE 
72C42BDB 
BF18E63D 
48009862 
B8A0001E 
3FC45235 
2281B63D 
4DBB1264 
FE67F 638 
D4D4B488 
FCF1D137 
CA595DE0 
91308B41 
3573BFAF 
E4ADC88B 
EE35C06B 
BC9C6D6A 
ECA8D732 
FB258877 
600DEB81 
1AE1AFAE 
B523073A 
O7211E7E 
446CE050 
5D4527F4 
2EB8D43F 
FBD4221E 
E2E32126 


BD6C8E93 
5A098649 
AE574155 
OEDFCD21 
12F20E95 
563EAFA1 
389AE443 
36E3BC7C 
15276754 
A6DAD428 
2733BE96 
48BDEEB2 
CD8FAE1F 
5C2A9917 
3FD94FC6 
CA63328F 
05746DAC 
31149618 
C66796EA 
1FEEA547 
52071945 
7ED91FE7 
C35B18A1 
149C441C 
2C8B0660 
28D45498 
4CF4F18B 
SOFF183A 
5B42AEFF 
17BAOF7C 
84117283 
7FFFFFFF 


48FBFBF7 
DE21BCA2 
CE4EFB4F 
6AE22427 
B34F0F78 
6B4FBO68C 
77DA18C5 
B8D6801C 
FCC68566 
FA20C170 
1029951D 
58E07EA6 
2723020F 
6DB1A06C 
0C1811E1 
3BE57CC9 
23D33E5F 
8AB15423 
E5677A01 
4D6D8F34 
67FA3555 
64A84EA1 
51D5C414 
E95782F2 
237EC128 
84B81FF7 
286090BD 
D2BBF118 
39585337 
60FF437F 
54FA30A7 
FFFFFFFF 


57EE2B10 
E649CEE7 
69EF8F6A 
DAAB8 9AF 
OEF8AC50 
E88454A5 
572B76F3 
601A0266 
E1LFF1D8D 
6379A513 
DELATA6F 
2CC6587D 
TATEA229 
743695E2 
055EF6835 
B737A961 
3BB1E78E 
76B50F00 
0494CCD1 
054148E6 
E345003F 
11DD2221 
59C74619 
9C40A3FD 
50077849 
AC3F1C6D 
77556011 
7CE4848D 
282EE416 
F64E8C08 
B1534A93 
1B568026 
B43FF5B4 
AAAD97BA 
2A282563 
AAOFE346 
OE1OBF36 
B1240B66 
C1FCOERAS 
6F697DD5 
535DFEF2 
OO8F154A 


Standards Track 


139E9E78 
124D9F7C 
EAFEB2BO 
3FABE4 9A 
9BS6F39A 
D96471FD 
B1B95D8C 
941A17BO 
A637D6B9 
60D977FD 
7CCEO11C 
60C36C8E 
716BA6E9 
911B1D06 
FD29EEF7 
8B26FA7D 
AA81A002 
96CF3419 
99E5C5BD 
E764BEE7 
2F06EC81 
657A9F53 
A6380E1D 
A67EDA3B 
1A8288F1 
OO3BECDA 
95140DFB 
A316A9C6 
DC2A19C5 
63139582 
6A18BOE0 
7B00641C 
F6E8EG62F 
3E499332 
C5BAC141 
4£435811 
10137296 
D6CD4AFC 
1F97D22B 
FDF2C518 
9833BF86 
41C7FC46 
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The estimated symmetric-equivalent strength of this group is 192 
bits. 


Peers using ffdhe8192 that want to optimize their key exchange with a 
short exponent (Section 5.2) should choose a secret key of at least 
400 bits. 
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